An inherent characteristic of software-defined networking (SDN) system is the physical separation of control and data plane entities. In this model, applications (or network services) running on top of a network controller manage network wide policies and instruct the network controller to either proactively or reactively install forwarding entries in network elements. The collection of forwarding entries in all network elements form the forwarding state of the network. The network controller serves as a network operating system that controls and manages these programmable network elements and provides a programmatic interface to the higher-level network management and control applications.
A SDN application, for example a service chaining solution, forwards packets based on matching packet header information against flow entries defined by the SDN application. The OpenFlow 1.3 Specification, a common SDN network configuration protocol, supports matching of most fields from the Open Systems Interconnections (OSI) headers of Layer 2, Layer 3, and Layer 4 (also referred to as L2-L4 or Layers 2-4).
A network element may fragment an IP packet when the maximum transmission unit (MTU) of a link on which the packet needs to be transmitted is identified to be smaller than the packet size. Typically, only the first fragment of a datagram (the datagram is often referred to as the “original” packet) carries all the header information including L4-L7 headers with the remaining fragments only including L2 and IP (L3) headers. Any forwarding or service mechanisms that depend on L4-L7 header information such as TCP port numbers will fail to process, or incorrectly process, fragmented packets as not all fragments carry this information. Thus, IP packet fragments pose a problem to SDN applications.
OpenFlow describes procedures for handling fragments but these solutions are not ideal and, in many cases, are not even a valid solution for a real-world network design. One approach is to reassemble the entire IP packet before processing any one fragment. That requires waiting for all fragments to arrive before processing the first fragment. This may degrade performance of the network element and introduce packet latency. Another approach is to use the non-reassembly option of OpenFlow 1.3. However, the non-reassembly option may result in first fragments and non-first fragments being given different forwarding behaviors, possibly leading to traffic loss.